Add labels support - #669
Open
fstachura wants to merge 15 commits into
Open
Conversation
This will allow us to store color codes cleanly in the database.
Labels are arbitrary bits of metadata attached to a submission. They can be used to signify priority, category, or other similar information. They can also be used to filter patches and identify the ones most interesting to a given user. Labels can be associated with a project to ensure that one project can use a totally different set of labels to another and to, in the future, allow a project administrator to use their own labels. However, they can also be global, which is useful for things that would be common across multiple projects such as "RFC".
fstachura
force-pushed
the
labels_m2m_final
branch
from
August 12, 2026 20:31
46d2c5c to
85fef0e
Compare
There are two added: a general labels view that includes both project and non-project labels, and an inline labels view that's part of the project.
This is required to ensure we can filter delegates by project. If we don't do this, our <select> gets stupid long, as seen in commit 198139e.
Nothing too complicated here. The forms we have for this need some serious cleanup/beautification, but that's a problem for another day.
One extra query is necessary for patch/cover endpoints to fetch labels information.
The filter allows filtering by project-specific and global labels. It also supports negative filtering. Prepending a label name with a minus sign excludes patches with that label from search results.
Patches in the API can be filtered by labels using the 'labels' query parameter.
a741c95 upgraded selectize to 0.13.5. However, it looks like a non-standalone version was uploaded by accident. On page load, the following error can be seen in debug console: "Selectize: Dependency MicroPlugin is missing". Because of that, the submitter autocomplete no longer works. Version 0.13.5 was not released on Github, so I have decided to upgrade the library to the latest available version. Add updated files to .gitattributes to skip them in patches.
Add autocomplete to labels field of update form in the patch details view (only visible for users with project admin rights).
The command re-parses subject headers of patches from given projects and adds label information to the database. The main usecase is to refresh label information on existing patches after adding a new label to the project.
fstachura
force-pushed
the
labels_m2m_final
branch
from
August 12, 2026 21:11
85fef0e to
cc81c15
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This series is a continuation of labels series published by Stephen Finucane
back in 2018.
Changes since v2:
I have started implementing series -> patch labels inheritance. It's not
included in this series as I'm not sure how it should work. As I understand
it, the name of the series may be changed as new patches are parsed.
I'm also not sure where in the UI users could see/modify labels for series.
This version uses a many-to-many relation for storing labels assigned to a
patch, like in v2. I understand that there is a performance concern as this
could cause excessive JOINs in queries. From what I can see, Django only uses
JOINs when patches are filtered by labels. When patches are just listed without
any filters, a separate query to the patch-labels table is executed instead
of a JOIN, that query seems to be rather cheap.
I have a POC alternative version that uses JSON columns to store an array with
labels inside the patches table.
So far it's not obvious to me that the JSON version is better performance-wise
(in my tests it sometimes was, sometimes not, especially on MySQL, that could be
an issue with my setup or the tests). Downsides: the code is more complex,
and I think there may be some issues around update atomicity.
Some of the commits from v2 were modified beyond just rebase and formatting.
I have retained the original author, unless the changes were really significant.
I'm submitting these patches now, I have added myself to Signed-off-by.
I'm not sure if this is 100% OK, so please let me know.
Sponsored-By: The Linux Foundation
Closes: #22